The Role Of Configuration Complexity In The Automotive Industry
Another aspect of configuration complexity is that each controller has different software components.
Khodrocar - Over the last 30 years, vehicle configuration complexity has increased almost exponentially. In the early '90s, vehicles had around 20 electronic control units (ECUs), with luxury models rounding out to about 25. Modern connected vehicles have between 100 and 150 ECUs, many of which control high-level functions that far exceed the programming requirements of the late 20th century. How are OEMs attempting to manage this increase in configuration complexity? Read on to find out.Understanding Configuration Complexity
Let's start by looking at where this complexity comes from. Take a car with 120 ECUs. Each of these components has several subsystems or sets of configurations based on the component type or make. This complexity only grows as we move toward a configurable skateboard-like electric vehicle (EV) architecture where the energy capacity of the EV is configured based on the number of inverters or the number of cell modules in the battery pack. We must also consider battery management systems that use different types of cells. For example, there might be a battery pack with LG cells for one region and Samsung cells for another.
Another aspect of configuration complexity is that each controller has different software components. Every controller has a bootloader—the software that allows the automaker to update the application code on the controller. Within the bootloader, there might be a primary and secondary bootloader. On top of that, there could be several different applications running on any given controller. Each application has its own source code and associated files—which, in turn, are tightly version-controlled and can undergo several different version changes per year.
The next layer of complexity is different vehicle trims. The feature codes associated with a premium trim will differ from a sport or base model. Then, there are the optional upgrades—adaptive cruise control, heated seats, lane assist, voice recognition and more. There are also geographical and homologation requirements. For example, a car produced in the U.S. and shipped to Mexico might have all of the same configurations as the U.S.-destined model except the infotainment system, which must be reconfigured through a variety of designated calibration parameters prior to shipment.
Finally, OEMs must consider component dependencies. Like any machine, vehicle components work together to perform a specific task. A compromised unit can (and often will) impact the overall safety, efficiency and functionality of the whole system. Every time an automaker updates the software version for one ECU, it must account for the impact on related components—which, again, may differ depending on the vehicle's make, model, trim, geographic location, production year and a number of other variables.
At this point, it should be quite obvious that managing all of this complexity and keeping an updated inventory is extremely challenging. Inefficient management can lead to mistakes such as flashing the incorrect configuration to a specific controller. Best-case scenario, the driver's infotainment system has some glitches or a shipment of vehicles is delayed due to geographic restrictions. In a worst-case scenario, the car doesn't start or the driver experiences a sudden loss of functionality.
Alleviating Complexity With OTA-Based Solutions
One way OEMs can alleviate the complexity of vehicle software configuration updates is by leveraging over-the-air (OTA) software solutions. This holistic approach can enable the definition of rules and configuration verification constraints to prevent the upload of invalid configurations, ensuring vehicle functionality and user safety. It doesn't rely on a person going in and manually looking at every vehicle manifest to determine what needs to be updated. Instead, it uses a single definition of target software across the entire fleet to update software configurations at scale.
How To Transition To An OTA-Based Solution
Although OTA solutions offer a range of benefits, implementing them can prove quite challenging. Fortunately, there are things automakers can do to ease the transition to an OTA-based solution for configuration management.
The first step is to set up a proper and consistent versioning system for all hardware and software. OEMs should be able to identify both what a piece of hardware is and where it belongs based on a combination of parts numbers and unique identifiers. Software versions should use unique identifiers, not just for specific versions on an ECU but also for bootloaders, applications and calibrations. This can help ensure version compatibility within each component and the system as a whole. For example, if battery management system (BMS) software sets the voltage limits for the powertrain, it needs to be compatible with the software running on the vehicle's powertrain ECU.
OEMs should use common applications wherever possible and leverage calibration files to address small deviations. Let's say a door controller module manages the functionality of all four doors, but there is a slight difference between the front and rear doors. In this situation, the application should be the same for every door, but the configuration file between the front and rear doors is different. This practice can also reduce the cost of OTA operations in that it only requires the download of a single update file rather than four independent downloads for each door.
In addition, common software must be preloaded onto the various ECUs and be designed to handle all possible feature configurations—even those that might remain inactive for the life of the vehicle. One example is heated seats. The code that manages heating should be present from the manufacturing phase but remain turned off unless the owner elects to purchase the feature.
The Future
As the landscape of the automotive industry continues to evolve, OEMs will need to adopt and implement an effective configuration management strategy. Those who select vehicle-wide OTA as the way forward can ease integration by setting up an appropriate versioning system, leveraging calibration files and preloading universal code prior to vehicle release. Taking these steps should reduce configuration complexity and overall costs as well as help OEMs stay ahead of the competition.
At this point, it should be quite obvious that managing all of this complexity and keeping an updated inventory is extremely challenging. Inefficient management can lead to mistakes such as flashing the incorrect configuration to a specific controller. Best-case scenario, the driver's infotainment system has some glitches or a shipment of vehicles is delayed due to geographic restrictions. In a worst-case scenario, the car doesn't start or the driver experiences a sudden loss of functionality.
Alleviating Complexity With OTA-Based Solutions
One way OEMs can alleviate the complexity of vehicle software configuration updates is by leveraging over-the-air (OTA) software solutions. This holistic approach can enable the definition of rules and configuration verification constraints to prevent the upload of invalid configurations, ensuring vehicle functionality and user safety. It doesn't rely on a person going in and manually looking at every vehicle manifest to determine what needs to be updated. Instead, it uses a single definition of target software across the entire fleet to update software configurations at scale.
How To Transition To An OTA-Based Solution
Although OTA solutions offer a range of benefits, implementing them can prove quite challenging. Fortunately, there are things automakers can do to ease the transition to an OTA-based solution for configuration management.
The first step is to set up a proper and consistent versioning system for all hardware and software. OEMs should be able to identify both what a piece of hardware is and where it belongs based on a combination of parts numbers and unique identifiers. Software versions should use unique identifiers, not just for specific versions on an ECU but also for bootloaders, applications and calibrations. This can help ensure version compatibility within each component and the system as a whole. For example, if battery management system (BMS) software sets the voltage limits for the powertrain, it needs to be compatible with the software running on the vehicle's powertrain ECU.
OEMs should use common applications wherever possible and leverage calibration files to address small deviations. Let's say a door controller module manages the functionality of all four doors, but there is a slight difference between the front and rear doors. In this situation, the application should be the same for every door, but the configuration file between the front and rear doors is different. This practice can also reduce the cost of OTA operations in that it only requires the download of a single update file rather than four independent downloads for each door.
In addition, common software must be preloaded onto the various ECUs and be designed to handle all possible feature configurations—even those that might remain inactive for the life of the vehicle. One example is heated seats. The code that manages heating should be present from the manufacturing phase but remain turned off unless the owner elects to purchase the feature.
The Future
As the landscape of the automotive industry continues to evolve, OEMs will need to adopt and implement an effective configuration management strategy. Those who select vehicle-wide OTA as the way forward can ease integration by setting up an appropriate versioning system, leveraging calibration files and preloading universal code prior to vehicle release. Taking these steps should reduce configuration complexity and overall costs as well as help OEMs stay ahead of the competition.
Latest News